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The  Navy  Distributed  Engineering  Plant  -  Value  Added  for  Fleet 

Jeffrey  H.  McConnell 


ABSTRACT 

The  Navy's  Distributed  Engineering  Plant 
(DEP)  was  rapidly  established  in  1 998  to 
address  critical  Fleet  interoperability  issues.  The 
primary  mission  of  the  DEP  and  its  associated 
testing  processes  is  to  characterize  the 
interoperability  of  each  deploying  Battle  Group 
and  provide  this  information  to  the  Battle  Group 
staff  along  with  the  acquisition  community.  The 
value  of  the  DEP  for  this  primary  mission  has 
been  proven  over  the  past  three  years  while  also 
establishing  new  DEP  roles  and  capabilities. 

For  instance,  in  fiscal  year  2001  the  DEP  team 
has  established  new  initiatives  to  help  program 
managers  find  and  resolve  problems  earlier  in 
the  acquisition  cycle.  As  an  example,  the 
Cooperative  Engagement  Capability  (CEC) 
program  is  now  the  second  largest  DEP  user 
after  the  core  mission  of  Battle  Group 
interoperability  testing.  In  addition,  processes 
and  tools  have  recently  been  established  that 
enable  the  DEP  to  measure  the  performance  of 
each  Battle  Group  as  a  total  system.  This  paper 
will  provide  a  brief  review  of  the  history  and 
capabilities  of  the  DEP  with  a  primary  focus  on 
the  value  added  of  the  DEP,  new  initiatives  and 
the  outlook  for  the  future. 

INTRODUCTION 

The  best  way  to  understand  the  DEP  is  to 
understand  the  interoperability  crisis  that  drove 
its  initial  inception  and  ongoing  evolution.  This 
understanding  will  explain  why  the  DEP  was 
built,  why  it  was  built  rapidly  and  why  it  is 
utilized  in  specific  ways  to  support  the  Fleet  on  a 
daily  basis. 

Examples  of  documented  Fleet 
interoperability  failures  are  far  too  numerous  to 
discuss  in  this  paper.  However,  one  well- 
documented  example  was  recorded  at  the  All- 
Service  Combat  Identification  Evaluation  Test  in 
1 997  (ASCIET  97).  This  event  occurred  on  the 
coast  of  Mississippi  and  brought  together  many 
Joint  service  systems  including  an  Army  Patriot 


battery.  Air  Force  AW  ACS  and  a  Navy  AEGIS 
Cruiser  off  the  coast.  In  many  ways  this  could 
be  viewed  as  a  highly  tuned,  highly  optimized 
environment  in  which  the  best  systems  were 
deployed  and  tuned  by  operators  and  engineers. 
In  a  very  graphic  demonstration  of 
interoperability  problems,  a  single  aircraft  flew 
through  the  ASCIET  97  operational  area,  but  the 
LINK- 16  network  indicated  three  different 
tracks,  three  different  track  identities  (unknown, 
friend  and  hostile)  and  three  track  numbers 
being  shared  for  that  one  aircraft.  Once  again, 
for  a  highly  tuned.  Joint  services  environment, 
this  was  the  best  picture  available  on  a  LINK- 16 
network  at  the  time. 

There  were  many  other  problems  that  drove 
the  interoperability  crisis.  The  rapid  evolution, 
severity  and  impact  of  these  problems  has 
‘snowballed’  over  many  decades  as  the  Navy 
rapidly  added  more  and  more  interoperability 
functionality,  such  as  LINK-11,  LINK-16  and 
the  CEC  network,  to  the  Fleet’s  combat  systems. 
In  1998  this  interoperability  crisis,  along  with 
problems  arising  from  the  introduction  of 
Commercial-Off-the-Shelf  (COTS)  technology, 
kept  the  AEGIS  cruisers  USS  HUE  CITY  (CG- 
66)  and  USS  VICKSBURG  (CG-69)  from 
deploying  with  their  Battle  Group. 

These  problems  and  many  other  frustrations 
in  the  Fleet  led  to  the  transmission  of  a  Fleet 
message  from  the  Commander-in-Chief  Atlantic 
Fleet  (CINCLANTFLT)  to  the  Chief  of  Naval 
Operations  (CNO)  that  said  in  part, 

“Resource  sponsors,  the  PEOs  and 
SYSCOM  structure  need  to  know  that 
despite  great  efforts  by  dedicated 
professionals,  they  have  failed  to  deliver 
integrated  war  fighting  capability  to  our 
Battle  Groups.” 

The  CNO  immediately  responded  with 
CNO  message  021648Z_MAY98  which 
established  Commander  Naval  Sea  Systems 
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Command  (NAVSEA)  as  the  authority  for 
resolving  Fleet  interoperability  issues. 
NAVSEA-53  was  assigned  primary 
responsibility  for  addressing  all  issues  required 
to  resolve  these  interoperability  problems. 

Initial  Solutions 

In  1998  NAVSEA-53  rapidly  initiated  a 
variety  of  corrective  solutions  to  address  the 
interoperability  problems  of  the  Fleet.  Many  of 
these  solutions  had  been  conceived  prior  to  1998 
and  even  partially  prototyped  in  some  cases  but 
all  were  rapidly  implemented  due  to  the 
criticality  of  the  situation. 

The  Navy  Distributed  Engineering  Plant 
(DEP)  and  the  Battle  Force  Interoperability  Test 
(BFIT)  were  two  important  solutions  that  were 
established  in  response  to  this  crisis.  The  DEP 
is  a  high-fidelity,  shore-based  Battle  Group 
testbed.  It  is  established  by  linking  together 
dispersed  combat  system  sites  around  the  United 
States.  When  activated,  the  DEP  network 
replicates  an  underway  Navy  Battle  Group  in  a 
controlled  and  repeatable  test  environment.  This 
networking  is  accomplished  by  utilizing  the 
basic  asynchronous  transfer  mode  (ATM) 
networking  technology  that  is  the  backbone  of 
the  Internet  today.  A  key  enabling  component 
of  the  DEP  is  the  KG-75  network  encryption 
device  developed  by  the  National  Security 
Agency.  The  KG-75  encrypts  network 
information  for  transmission  across  public 
telephone  networks  without  fear  of 
compromise.  The  dynamic  capability  of  the 
KG-75  provides  an  extraordinary  amount  of 
flexibility  for  deployment  and  management  of 
the  DEP  network  around  the  country  and 
throughout  the  world. 

As  with  any  tool,  the  DEP  is  of  little  use 
if  there  is  not  a  team  capable  of  utilizing  it  to 
test  the  deploying  Battle  Groups.  The  BFIT  is 
the  battery  of  tests  developed  and  executed  by 
the  BFIT  test  team  to  test  the  interoperability  of 
every  deploying  Battlegroup.  The  BFIT  utilizes 
the  DEP  as  the  high-fidelity  tool  to  test  every 
Battle  Group,  characterize  its  interoperability 
and  report  the  results  to  the  deploying  Battle 
Group  command  staff  Discussion  will  begin 


with  the  DEP  and  the  BFIT  and  then  branch  into 
other  ways  that  the  DEP  is  being  utilized. 

A  Brief  History  of  the  DEP/BFIT 

This  paper  will  not  go  into  great  detail 
regarding  the  history  of  the  DEP  or  how  it 
conceptually  functions.  Readers  may  consult 
several  sources  for  this  backgroimd  information 
including  an  article  titled  “The  Navy  Distributed 
Engineering  Plant”  published  in  the  May/June 
2000  edition  of  Surface  Warfare  Magazine.  The 
body  of  that  same  article  is  available  for 
download  from  the  DEP  website  at 
http://\TOVv.nswc.navv.mil/dcp. 

In  the  Spring  of  1998,  in  response  to  the 
CNO  message  021648Z_MAY98,  NAVSEA-53 
stood  up  a  task  force  to  investigate  various 
aspects  of  interoperability  resolution.  A  primary 
focus  of  the  task  force  was  to  investigate  the 
possibility  of  federatmg  land  based  combat 
system  sites  to  form  a  shore-based  Battle  Group 
testbed.  The  task  force  met  for  six  weeks  in 
Washington  D.C.  and  reported  in  June  1998  that 
the  DEP  concept  was  “technically  feasible  but 
would  be  organizationally  difficult”. 


Figure  1  -  The  DEP  Alliance 
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Shortly  after  the  delivery  of  the  task  force 
report  an  Alliance  of  Navy  laboratories  was 
formed  to  develop  a  proposal  to  establish  the 
DEP  and  BFIT  for  NAVSEA.  The  DEP 
Alliance,  as  it  is  called,  consisted  of  14 
laboratories  as  depicted  in  Figure  I.  12  of  the 
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laboratories  were  from  the  three  Navy  systems 
commands  (NAVSEA,  NAVAIR  and 
SPAWAR)  along  with  the  Naval  Research  Lab 
and  the  Applied  Physics  Laboratory  of  the  Johns 
Hopkins  University.  The  DEP  Alliance  met  all 
through  the  summer  of  1 998  and  developed  a 
detailed  proposal  that  described  all  of  the 
resources  and  talent  that  would  be  required  to 
establish  both  the  DEP  and  the  BEIT  team.  That 
proposal  was  finalized  and  presented  to  a  Flag 
review  board  on  September  18,  1998.  The  board 
endorsed  the  idea  and  tasked  the  Alliance  to 
establish  the  DEP  and  BFIT  in  four  months  in 
order  to  be  ready  to  test  the  John  F.  Kennedy 
(JFK)  Battle  Group  in  time  for  her  deployment. 

The  DEP  was  established  by  the  DEP 
Alliance  in  that  four  month  period  and  the  JFK 
BFIT  commenced  on  January  20,  1999.  Results 
found  in  the  BFIT  testing  correlated  very  well 
with  problems  seen  at  sea  and  detailed 
information  was  provided  to  the  JFK  Battle 
Group  staff.  Over  the  period  of  one  year 
through  January  26,  2000  the  DEP  team 
executed  four  BFITs  covering  five  total  Battle 
Groups  (the  last  BFIT  combined  two  very 
similar  Battle  Group  configurations  into  one 
test).  As  of  the  fall  of  2001  the  DEP  has 
executed  9  BFITs  covering  a  total  of  14 
deployed  Battle  Groups. 

DEP  VALUE-ADDED 

The  balance  of  this  discussion  will  focus  on 
the  value-added  and  contributions  provided  to 
the  Fleet.  The  value-added  provided  by  the  DEP 
is  presented  in  four  sections:  1)  Battle  Group 
Deployment;  2)  Problem  Resolution;  3)  Battle 
Group  Capability  Development  and  4)  Battle 
Group  Performance  Measurement. 

DEP  Value-Added: 

Battle  Group  Deployment 

Testing  each  deploying  Battle  Group  prior 
to  deployment  is  the  primary  mission  of  the  DEP 
as  required  in  the  Navy’s  Battle  Group 
deployment  preparation  instruction 
(CINCLANTFLT/  CINCPACFLT  Instruction 
4720.3A). 


To  clarify  and  distinguish  a  previous  point, 
the  DEP  is  a  massive,  distributed  tool  that 
emulates  a  Battle  Group  and  the  BFIT  is  a 
specific  test  event  (eomposed  of  plans, 
procedures,  teams  and  processes)  that  is 
executed  for  each  deploying  Battle  Group. 
Together  since  1998  the  DEP/BFIT  team  has 
uncovered  numerous  interoperability  problems 
and  has  been  the  stimulus  for  initiation  of 
several  new  programs  to  further  enhance  Fleet 
combat  readiness.  These  new  programs  will  be 
discussed  in  more  detail  in  later  sections. 

One  way  of  visualizing  the  BFIT  is  as  a 
staircase  with  each  step  building  on  the  previous 
step.  At  the  start  of  a  BFIT,  testing  begins  by 
establishing  and  testing  simple  Battle  Group 
connectivity.  Then,  overall  complexity  is 
steadily  increased  over  a  5-week  period.  For 
example,  the  BFIT  begins  with  one  LINK-1 1 
network,  adds  LINK-16  and  then  CEC.  BFIT 
concludes  with  all  communications  networks 
operating  simultaneously.  The  BFIT  team  tests 
the  total  Battle  Group  in  its  planned  deployment 
configuration  including  the  specific  OPT  ASK 
LINK  requirements  and  Identification 
supplement  for  the  Battle  Group’s  deployment 
theater. 

Since  the  commissioning  of  the  DEP,  the 
complexity  and  productivity  of  the  BFIT  testing 
has  grown  significantly.  For  example,  the  first 
JFK  BFIT  was  very  comprehensive  and  accurate 
but  the  following  BFIT  for  the  Eisenhower 
Battle  Group  was  far  more  complex  and  difficult 
with  the  addition  of  CEC,  Global  Command  and 
Controls  System-Maritime  (GCCS-M)  and  other 
improvements.  The  BFIT  testing  has  now  come 
full  circle,  with  the  completion  of  the  second 
JFK  BFIT  in  the  summer  of  2001 . 

In  the  summer  of  2001  the  JFK  Battle 
Group  underwent  DEP  testing  for  the  second 
time.  Several  new  innovations  were 
implemented.  For  the  first  time,  the  Surface 
Warfare  Development  Group  (SWDG)  joined 
with  the  BFIT  team  for  specialized  testing. 
SWDG  was  responsible  for  developing  a 
Tactical  Memo  (TACMEMO)  to  support  the 
Operational  Evaluation  (OPEVAL)  of  CEC  on 
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the  JFK  Battle  Group  in  May  of  2001 . 

However,  this  TACMEMO  could  not  support 
the  JFK  deployment  several  months  after 
OPEVAL  since  many  configuration  details  such 
as  the  CEC-capable  E-2C  would  not  be  included 
in  the  deployment  configuration.  SWDG  had  to 
rapidly  strip  the  OPEVAL  TACMEMO  down 
and  rebuild  it  into  a  deployment  TACMEMO. 
This  did  not  leave  any  time  in  the  pre¬ 
deployment  schedule  for  SWDG  to  validate  the 
new  deployment  TACMEMO  prior  to  turning  it 
over  to  the  Fleet.  The  BFIT  teams  set  aside  two 
nights  during  the  JFK  BFIT  for  SWDG  testing 
of  the  TACMEMO.  The  BFIT  test  team 
provided  the  expertise  to  write  the  test 
procedures  and  execute  the  test.  The  SWDG 
team  was  also  able  to  verify  and  improve  many 
aspects  of  the  final  TACMEMO  and  the 
collaboration  was  very  successful  and  will 
greatly  benefit  the  Fleet. 

Another  innovation  implemented  in  the 
JFK  BFIT  was  the  dedication  of  two  days  of 
testing  for  the  collection  of  Battle  Force 
Interoperability  Requirements  (BFIR)  metrics 
data.  The  BFIR  metrics,  processes  and  results 
will  be  described  in  more  detail  later  in  the 
fourth  value-added  module. 

BFIR  metrics  had  been  collected  in 
previous  DEP  events  but  the  JFK  BFIT  provided 
dedicated  test  days  in  order  to  prove  the  value  of 
measuring  the  performance  of  each  Battle  Group 
prior  to  deployment  and  in  order  to  establish  a 
baseline  for  comparison  to  upcoming  Battle 
Groups.  BFIR  data  collection  events  will  be 
conducted  in  the  DEP  for  all  deploying  Battle 
Groups.  This  will  provide  a  common  baseline  of 
performance  information  across  all  Battle 
Groups,  valuable  insights  and  understanding  to 
each  deploying  Battle  Group  staff  and 
comparative  metrics  for  the  developmental 
community. 

BFIT  Products 

The  primary  product  of  the  BFIT  for  all 
deploying  Battle  Groups  is  the  Data 
Management  and  Analysis  Report  (DMAR). 

This  document  captures  all  the  test  results  of  a 
BFIT  including  what  was  tested,  how  it  was 


tested  and  all  results  for  the  Battle  Group.  An 
important  sub-product  coming  out  of  the  DMAR 
is  input  data  for  the  Battle  Group  Capabilities 
and  Limitations  (Caps  and  Lims)  document. 

This  document,  produced  by  NAVSEA/Port 
Hueneme,  captures  the  platform  level  Caps  and 
Lims  of  each  platform  as  documented  by  the 
platform  managers.  With  the  advent  of  the 
BFIT,  this  document  also  captures  the  Caps  and 
Lims  of  the  Battle  Group  as  a  system.  The  BFIT 
team  also  provides  comments  to  the  techniques 
and  procedures  to  be  employed  by  the  Battle 
Group  staff  as  well  as  comments  on  the 
OPT  ASK  and  other  initial  setup  procedures. 

Trouble  Reports  (TRs)  documented  during 
the  BFIT  are  submitted  to  and  stored  in  a 
NAVSEA-53H  central  database  and  are 
provided  to  the  Software  Support  Activities 
(SSAs)  and  program  offices  responsible  for  the 
resolution  of  these  problems.  This  collection  of 
information  into  a  single  repository  has  proven 
invaluable  in  uncovering  trends  that  identify 
functional  failure  areas  common  to  all  Battle 
Groups  as  well  as  for  measuring  and 
documenting  improvement  between  Battle 
Groups.  This  information  in  turn  has  driven 
problem  resolution  initiatives  that  will  be 
discussed  in  the  next  value-added  module. 

BFIT  As  a  Battle  Group  System 
Integration  Milestone 

Another  unique  aspect  of  the  BFIT  is  the 
concept  of  Battle  Group  system  integration  and 
debugging.  This  concept  is  not  usually 
documented  or  discussed  but  rapidly  becomes 
apparent  to  those  familiar  with  system 
development. 

Prior  to  the  existence  of  the  DEP  and  BFIT 
process,  there  was  a  structured,  six-month  pre¬ 
deployment  readiness  process  for  each 
deploying  Battle  Group.  The  ‘Achilles  heel’  of 
this  process  was  that  the  first  time  the  Battle 
Group  came  together  as  a  total  warfighting 
system  was  during  the  Battle  Group  System 
Integration  Test  (BGSIT).  During  BGSIT  the 
ships  and  aircraft  of  the  Battle  Group  first 
worked  together,  at  sea,  as  a  team,  for 
integration,  training  and  workups.  At  a  more 
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fundamental  level,  this  meant  the  Battle  Group 
Sailors  were  executing  the  functions  of  system 
integration  and  system  debug  instead  of 
performing  their  intended  at-sea  function... 
operational  training. 

With  the  advent  of  the  DEP  and 
NAVSEA’s  new  30-month  deployment 
preparation  process  (the  “D-30”  or  ‘deployment- 
minus-30  months’  process  as  documented  in 
Instruction  4720. 3A),  the  DEP  is  now  utilized  to 
exercise  a  large  portion  of  the  Battle  Group 
combat  systems  ashore  during  a  BFIT  prior  to 
the  Battle  Group  coming  together  at  sea. 

Even  though  the  BFIT  is  executed  to 
specifically  characterize  the  interoperability  of 
each  Battle  Group,  the  DEP  tool  and  BFIT 
process  have  shifted  a  large  portion  of  the  Battle 
Group  system  integration  and  debug  process 
back  ashore  where  it  belongs.  An  accredited 
replica  of  each  Battle  Group’s  combat  systems 
hardware  and  computer  programs  now  spend  5 
weeks  (15  eight-hour  periods)  in  a  highly 
controlled  environment  as  the  BFIT  team 
executes  this  fundamental  systems  integration 
activity.  Valuable  and  much  more  expensive 
BG  underway  time  is  now  much  more  focused 
on  underway  operational  training.  Problems  and 
work-arounds  are  reported  to  the  Fleet.  Now, 
Fleet  Sailors  go  to  sea  and  train  to  fight  instead 
of  finding  and  resolving  combat  system 
interoperability  problems. 

Credibility 

There  are  many  different  ways  to  measure 
“Value-Added”.  The  most  desirable  method  is 
direct  feedback  from  the  customer.  In  this  case 
the  Fleet,  as  the  customer,  is  seeing  the  value  of 
the  DEP/BFIT  program  ashore.  This  value- 
added  is  and  has  been  documented  in  many 
messages  from  the  Atlantic  and  Pacific  Fleet 
Commanders.  The  DEP  and  BFIT  is  working. 
There  is  now  documented  evidence  that  the  Fleet 
is  spending  a  significantly  higher  percentage  of 
the  BGSIT  event  training  vice  debugging 
interoperability  failures  within  the  Battle  Group. 


DEP  Value-Added: 

Problem  Resolution 

The  second  DEP  value-added  module  takes 
a  look  at  Battle  Group  problem  resolution. 
Shortly  after  the  DEP  stood  up,  questions  arose 
as  to  how  the  DEP  could  be  employed  to  resolve 
the  interoperability  problems  that  were  being 
found.  The  conventional  answer  was  to  ‘pass 
the  buck’  to  the  platform  program  managers  and 
their  SSAs  who  were  responsible.  However, 
DEP  personnel  knew  the  DEP  could  play  a  large 
part  in  the  problem  resolution  process  and 
wanted  to  be  a  part  of  the  engineering  of 
solutions  for  the  Fleet’s  combat  system 
interoperability  failures. 

In  the  summer  of  2000  the  DEP  team 
proposed  a  multi-pronged  approach  to 
NAVSEA-53  for  the  fiscal  year  2001  program. 
First,  the  DEP  teams  would  continue  to  test  each 
deploying  Battlegroup  as  mandated  by 
Commander  NAVSEA  and  the  joint- 
CINCLANTFLT/CINPACFLT  instruction 
4720.3A.  This  is  and  continues  to  be  the 
primary  mission  of  the  DEP.  At  the  same  time, 
the  DEP  team  would  undertake  initiatives  to 
help  provide  “near-term”  solutions  as  well  as 
“long-term”  solutions  to  the  Fleet’s  combat 
systems  interoperability  problems.  This 
approach  was  approved  by  NAVSEA-53,  has 
been  implemented  and  has  been  proven  very 
successful. 

Interoperability  System  Engineering  Test 
(ISET) 

The  ISET  or  Interoperability  System 
Engineering  Test  executed  in  the  DEP  examines 
“root  cause”  of  interoperability  problems 
discovered  during  prior  BGITS  conducted  in  the 
DEP.  The  ground  rules  for  an  ISET  are: 

1)  Focus  on  high  priority  Trouble  Reports 
(TRs)  with  a  high  severity  and  high  probability 
of  occurrence. 

2)  Focus  further  on  Frequent  Offenders  or 
problems  that  have  plagued  the  Fleet  for  many 
years. 
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3)  These  TRs  must  have  a  high  probability 
of  re-occurrence.  Essentially,  if  a  problem 
appeared  one  time  on  the  phosphor  of  a  screen 
and  disappeared  -  to  never  be  seen  again  -  no 
time  would  be  devoted  to  checking  into  it. 
However,  if  a  problem  has  been  seen  often,  it  is 
worthwhile  to  commit  Battle  Group  system  test 
assets  to  the  resolution  of  that  problem. 

4)  These  problems  must  have  a  high 
probability  of  successful  implementation.  This 
means  that  the  DEP  team  would  focus  only  on 
problems  that  were  in  active  combat  system 
baselines  and  were  not  slated  for  resolution  in 
the  newest  software  upgrade  being  developed. 
Therefore,  newly  discovered  and  some  lingering 
problems  have  a  high  probability  of  being  fixed 
by  the  program  SSAs.  Many  programs  fall  into 
this  category  including  ACDS  Block  0  carrier 
combat  system  that  will  be  in  the  Fleet  for  many 
years  to  come.  On  the  other  hand,  if  a 
program/platform  is  in  “caretaker”  status  -  no 
money  is  available  to  fix  problems  or  upgrade 
the  system  -  there  is  little  value  in  drilling  down 
to  find  solutions. 

The  ISET  Process 

The  key  to  making  the  ISET  process  work 
was  partnering  with  the  respective  SSAs  that  are 
responsible  for  the  primary  combat  systems 
involved  in  the  ISETs.  The  DEP  network  and 
infrastructure  were  provided  as  a  Battle  Group 
tool  with  the  DEP  team,  SSA  engineers  and 
programmers  manning  the  combat  system 
consoles.  During  the  ISET,  the  DEP  is  used  to 
federate  a  small  Battle  Group  and  the  Battle 
Group  is  tested  in  this  configuration  for  several 
nights.  In  contrast  to  BFIT  testing,  this  is  more 
of  an  iterative  testing  process  performed  with  an 
engineering/tester  approach  -  find  a  problem, 
back  up,  retest,  try  different  parameters  and  in 
essence  help  the  engineers  and  programmers  to 
isolate  faults  to  the  computer  code  level. 

The  ISET  execution  cycle  consists  of  four 
major  steps.  ISET  test  #1  validates  the  ISET 
process.  ISET  test  #2  actually  drills  down  to 
discover  the  root  cause  of  the  target  problem  list. 
ISET  test  #3  is  executed  to  re-test  any  aspects  of 
the  ISET  test  #2  findings  that  need 
amplification.  Between  ISET  test  #2  and  ISET 


test  #4  the  SSAs  implement  fixes  for  problems 
found  earlier.  ISET  test  #4  validates  the 
solutions.  The  ISET  fix  cycle  is  timed  to  occur 
within  the  normal  development  cycle  of  the 
individual  platform  processes. 

ISET  tests  #1,  #2  and  #3  were  executed 
within  FY200 1 .  Due  to  resource  limitations, 
ISET  #4  is  planned  to  occur  in  FY2002  leading 
to  final  validation  of  the  problem  resolutions  and 
the  ISET  process  in  general.  Preliminary 
findings  and  indications  have  shown  the  ISET 
concept  to  be  a  very  powerful  tool  for  Battle 
Group  system  problem  resolution. 

DEP  Value  Added: 

Battle  Group  Capability  Development 

The  third  DEP  Value  Added  module 
addresses  support  to  Battle  Group  capability 
development.  This  is  an  initiative  in  which  the 
DEP  is  being  utilized  to  assist  the  acquisition 
community  in  building  better  systems  before 
they  commence  the  D-30  process  and  ultimately 
deploy  with  a  Battle  Group. 

Figure  II  shows  the  level  of  DEP  support 
now  being  provided  to  the  acquisition 
community.  The  metric  on  this  pie  chart  is  the 
number  of  hours  that  the  DEP  ATM  network 
was  actually  utilized  by  various  programs.  The 
DEP  ATM  network  is  actually  available  365 
days  a  year,  24  hours  a  day  and  the  DEP  utilized 
that  network  a  total  of  2 1 00  hours  in  F Y200 1 . 


Figure  II -DEP  Utilization 
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Although  BFIT  is  the  primary  mission  of 
the  DEP,  a  close  examination  of  Figure  II  shows 
that  the  DEP  was  actually  used  more  in  FY  2001 
to  support  developmental  programs.  Support  to 
BFIT  testing  took  26%  of  the  DEP  ATM  time  in 
FY  2001  as  compared  to  45%  for  supporting 
developmental  programs.  The  data  in  Figure  II 
includes  actual  test  execution  time  as  welt  as 
bulk  data  transfers  and  other  support  services. 
Figure  II  also  shows  that  the  DEP  supplied  10% 
of  the  ATM  utilization  to  Battle  Group 
performance  measurement  (to  be  discussed  in 
more  detail  later),  5%  to  perform  integration 
tasks  as  the  Joint  DEP  (JDEP)  sites  were  added 
to  the  DEP  and  14%  for  plant  validation,  plant 
upgrades  and  maintenance. 

The  FY  2001  DEP  utilization  data  clearly 
documents  the  DEP’s  growing  and  continued 
contribution  to  NAVSEA’s  systems 
development  mission  and  documents  the 
realization  of  another  of  the  founding  visions  for 
the  DEP  ...  specifically,  to  enable 
interoperability  testing  of  new  systems  much 
earlier  in  their  acquisition  cycle  in  order  to 
deliver  interoperable  systems  to  the  Fleet  the 
very  first  time  they  go  to  sea. 

With  NAVSEA’s  concurrence,  DEP  is  now 
providing  the  ATM  network  and  some  test 
infrastructure  to  the  developmental  communities 
to  enable  them  to  provide  a  better  product  to  the 
Fleet.  In  most  cases  these  programs  are  paying 
for  combat  system  site  costs  as  well  as  the  cost 
of  manning  those  sites.  Therefore  there  is  tittle 
additional  cost  to  NAVSEA-53  other  than  the 
sunk  cost  of  the  ATM  bandwidth. 

Primary  users  within  the  developmental 
community  include  the  CEC  program,  the 
AEGIS  program  for  multi-platform  testing,  the 
ISETs  that  were  just  described  and  Collaborative 
Systems  Tests  (CSTs)  which  will  be  described 
next. 


Collaborative  Systems  Tests  (CSTs) 

The  DEP  again  proved  its  worth  and  value 
added  in  the  summer  of  FY  2001 .  The  JFK 
Battle  Group  was  working  up  again  for  its 


second  deployment  since  the  DEP  was 
established.  The  Battle  Group  was  scheduled  to 
deploy  this  time  with  the  USS  HUE  CITY  and 
USS  VICKSBURG  AEGIS  cruisers.  Pre¬ 
deployment  milestones  were  tightly  compacted 
with  CEC  OPEVAL  scheduled  on  the  JFK 
Battle  Group  in  May  of  FY2001  and  the  JFK 
BFIT  scheduled  just  one  month  later.  In 
response  to  the  pressures  related  to  this  Battle 
Group,  CSTs  were  proposed  and  approved  as  a 
risk  mitigation  step  to  help  shepherd  the  JFK 
Battle  Group  through  critical  interoperability 
and  operational  testing  milestones. 

The  philosophy  of  the  CST  was  to  preview 
the  interoperability  performance  of  a  Battle 
Group  earlier  in  the  D-30  cycle  in  order  to 
discover  and  correct  interoperability  problems 
during  the  developmental  cycle.  This  was 
achieved  by  establishing  a  mini  Battle  Group 
over  the  DEP  ATM  network,  using  early 
developmental  system  computer  program  loads 
and  manning  the  platform  consoles  with  SSA 
engineers  and  programmers.  This  enabled  the 
engineers  and  programmers  to  see  how  their 
respective  systems  performed  as  a  part  of  the 
Battle  Group  system.  The  hope  was  that 
problems  seen  by  the  platform  development 
personnel  could  be  fixed  prior  to  the  OPEVAL, 
the  BFIT  and  the  eventual  Battle  Group 
deployment. 

Results  are  still  under  development  for 
several  platforms  but  one  big  success  story 
comes  from  the  first  JFK  CST  event.  During 
this  event,  four  key  problems  were  diseovered 
with  the  FFG-7  class  guided  missile  frigates  and 
their  Combat  Direction  System  (CDS)  computer 
programs.  This  system  is  essentially  in 
caretaker  status  meaning  no  fixes  will  be 
implemented  on  this  system.  In  this  case 
however  the  CDS  program  manager  approved 
resources  to  fix  the  four  problems,  generating 
the  CDS  Level  13,  patch  version  0004X  that  was 
ultimately  tested  in  JFK  BFIT  and  will  deploy 
with  the  JFK  Battle  Group. 

For  years  the  FFG  CDS  has  caused 
intolerable  problems  on  the  Battle  Group  LINK- 
1 1  network  and  relegated  the  FFGs  to  operate  in 
LINK-1 1  “receive-only”  mode.  Bottom  line  ... 
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repairs  stemming  from  the  CST  have  enabled  the 
JFK  Battle  Group  to  regain  foil  utility  of  its  FFG 
resources  in  two-way  LINK-1 1  operations. 

CEC  Development 

The  CEC  program  has  been  another 
benefactor  of  the  DEP’s  developmental  support 
capability.  Shortly  after  the  DEP  was 
established,  the  CEC  program  approached  the 
DEP  management  team  and  began  to  use  the 
DEP  to  test  the  CEC  system.  Prior  to  the  DEP, 
CEC  performed  as  much  testing  ashore  as 
possible,  performing  CEC  system  integration 
and  CEC-to-combat  system  integration  at  the 
land  based  combat  system  sites.  However,  as  a 
multi-ship  capability,  the  bulk  of  CEC  testing 
had  to  be  performed  in  a  multi-ship 
environment.  This  required  live  testing  on  an 
underway  Battle  Group.  Not  only  was  this 
expensive  for  the  Fleet  Commanders  to  support 
but  from  an  engineering  perspective,  it  was  also 
far  from  satisfactory.  The  live  Battle  Group  as  a 
‘testbed’,  albeit  very  high  in  fidelity,  was  very 
inefficient  in  terms  of  providing  a  “controlled 
and  repeatable”  environment  necessary  to  foster 
“engineered”  solutions. 


Figure  III  -  CEC  Testing  ImprcKements  | 
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As  shown  on  the  left-hand  pie  chart  of 
Figure  III,  prior  to  the  DEP  the  CEC  IV&V  team 
had  to  test  79%  of  302  Cooperative  Engagement 
Processor  (CEP)  requirements  on  the  live  Battle 
Group  ships.  With  the  advent  of  the  DEP,  the 
CEC  IV&V  team  has  rapidly  become  the  DEPs’ 
second  largest  user  and  is  now  able  to  test  46% 
of  their  requirements  in  the  DEP  leaving  33%  to 


be  tested  on  the  live  ships  as  shown  in  the 
middle  pie  chart. 

The  third  pie  chart  is  provided  as  an 
illustration  of  how  DEP  fidelity  improvements 
provide  an  additional  positive  impact  for  the 
Fleet.  The  DEP  has  always  incorporated  the  real 
CEP  portion  of  CEC  but  never  the  Data 
Distribution  System  (DDS).  The  DDS  contains 
over  200,000  lines  of  code  and  a  significant 
amount  of  CEC  functionality.  This  functionality 
and  the  behavior  of  the  DDS  network  has  been 
emulated  in  the  DEP  via  the  use  of  a  Wrap- 
Around  Simulation  Program  (WASP). 

The  CEC  program  is  currently  constructing 
several  400-foot  towers  on  the  East  Coast. 

These  towers  have  a  real  CEC  antenna  and  the 
real  DDS  cabinet  of  the  CEC  system. 

Meanwhile,  the  DEP  team  along  with  the  CEC 
team  is  evaluating  how  to  employ  the  DEP  ATM 
network  to  take  land-based  combat  systems  with 
their  CEPs  and  ‘connect’  them  to  the  DDS  at  the 
towers.  This  would  effectively  allow  any  shore- 
based  combat  system  on  the  DEP  to  participate 
in  a  live  CEC  network  (including,  potentially, 
ships  offshore).  This  would  bring  the  live  DDS, 
along  with  its  200,000  lines  of  code,  into  the 
DEP  architecture  and  allow  the  CEC  IV&V 
team  to  test  an  additional  1 5%  of  the  CEC 
requirements  ashore.  CEC  live  Battle  Group 
testing  requirements  are  projected  to  be  further 
reduced  downward  to  1 8%. 

For  the  CEC  program  the  benefits  of  using 
the  DEP  have  proven  to  be  very  significant.  The 
CEC  program  is  now  able  to  more  rigorously 
test  ashore,  as  a  system,  in  a  repeatable, 
controlled  environment.  This  leads  to  the  ability 
to  deliver  a  better  product  to  the  Fleet  while 
reducing  the  impacts  to  the  Fleet  schedule, 
training  and  quality  of  life. 

DEP  Value  Added: 

Battle  Group  Performance 

The  ability  to  measure  the  performance  of 
any  system  against  a  ‘yardstick’  is  critical  to  any 
systems  engineering  function  as  it  supports  an 
acquisition  program.  The  metrics  provided 
indicate  system  capability,  functionality. 
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developmental  progress  and  potential  for  system 
improvement  and  investment.  This  final 
discussion  module  takes  a  look  at  how  the  DEP 
is  being  utilized  to  measure  the  performance  of 
the  Battlegroup  as  a  single  system. 

Establishing  BFIR  Metrics 

The  ability  of  the  DEP  to  measure  total 
Battle  Group  system  performance  is  rooted  in 
another  program  called  the  Battle  Force 
Interoperability  Requirements  (BFIR)  program. 
Sponsored  by  NAVSEA-53C,  the  BFIR  program 
was  established  in  the  1999/2000  timeframe  to 
address  questions  arising  from  the  CNO-N8  and 
Assistant  Secretary  of  the  Navy  /Research, 
Development  and  Acquisition  (ASN(RDA)) 
organizations  with  respect  to  Battle  Group 
performance. 

N8  was  seeking  methods  to  measure  the 
performance  and  interoperability  of  Battle 
Groups  as  the  systems  and  sub-systems  of  the 
Battle  Group  are  acquired,  deployed  and 
upgraded.  In  a  similar  manner,  ASN(RDA)  was 
preparing  to  make  TRIP  #2  (Low  Rate  Initial 
Production),  LRIP  #4  and  [eventually]  Full  Rate 
Production  (FRP  )  decisions  for  the  CEC 
program  and  needed  Battle  Group-level  metrics 
that  could  demonstrate  the  value-added  to  the 
Fleet  if  the  CEC  system  was  to  be  procured  and 
deployed.  These  metrics  would  be  utilized  to 
help  make  the  upcoming  milestone  decisions. 

NAVSEA-53C  undertook  the  task  of 
developing  this  detailed  level  of  metrics  and 
established  the  BFIR  team.  Working  with  N8 
and  ASN(RDA),  the  BFIR  team  described  a 
high-level  metric  called  Track  Information 
Quality  (TIQ).  TIQ  consists  of  6  metrics  that 
expand  to  26  sub-metrics.  The  BFIR  team 
worked  to  rapidly  define  all  levels  of  this  metric 
hierarchy  and  then  began  the  work  of  developing 
a  metrics  collection  methodology  as  well  as  the 
algorithms  and  tools  needed  to  produce  the  sub¬ 
metrics  and  then  roll-up  the  TIQ  metric. 

A  primary  goal  of  the  BFIR  team  is  to 
utilize  the  metrics  developed  and  the  measured 
values  of  those  metrics  to  write  a  Battle  Force 
Interoperability  Capstone  Requirements 


Document  (BFI  CRD).  This  CRD  will  help  the 
Navy  to  specify  the  performance  of  the  Battle 
Group  as  a  system  and  provide  requirements  to 
develop  towards  in  the  future. 

Track  Information  Quality 

Before  understanding  how  the  BFIR/DEP 
relationship  is  adding  value  for  the  Fleet,  TIQ 
and  its  application  to  Battle  Group  performance 
measurement  must  be  understood. 

TIQ  is  a  rollup  of  many  sub-metrics  into  an 
aggregate  measure  of  Battle  Group  shared 
situational  awareness.  It  describes  the  quality 
of  information  shared  by  all  commanders  within 
the  Battlegroup  with  respect  to  a  track.  For 
purposes  of  this  paper,  all  tracks  are  air  tracks. 


As  shown  in  Figure  IV,  TIQ  begins  at  level 
1  which  is  described  as  “Unit  Track 
Awareness”.  This  level  indicates  that  an  aircraft 
or  missile  has  entered  the  detection  range  of  the 
Battle  Group  and  a  Battle  Group  ship  or  aircraft 
has  developed  a  sensor  track  on  that  object.  The 
detecting  unit  has  not  transmitted  any  track 
information  onto  the  data  LINKs. 

Level  2  is  called  “Force  Track  Awareness”. 
At  this  level,  information  about  the  track  has 
been  transmitted  over  a  LINK  and  other  Battle 
Group  commanders  are  aware  of  the  track.  It 
does  not  mean  that  this  is  a  high  quality  track 
with  good  positional  and  identification 
information. 
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Level  3  is  actually  made  up  of  two 
branches,  3i  and  3t.  3t  is  referred  to  as  a  high- 
fidelity  track.  This  indicates  that  high  quality 
kinematic  information  is  being  shared  on  the 
LINKS  for  this  track.  Essentially  its  position  and 
velocity  are  correctly  measured  and  have  been 
shared  on  the  LfNKs.  3t  also  means  that  there 
are  no  dual  tracks  or  multi-track  information  on 
the  LfNKs.  3i  on  the  other  hand  means  that  the 
identification  (ID)  has  been  correctly  resolved 
and  accurately  reported  to  all  commanders  in  the 
Battle  Group. 

Level  4  is  defined  as  the  simultaneous 
achievement  and  maintenance  of  both  3i  and  3t. 
In  other  words,  at  level  4,  the  Battle  Group  has 
achieved,  and  fully  shares  an  unambiguous  track 
for  the  object.  This  means  that  all  Battle  Group 
commanders  share  the  same  picture  for  that 
track  with  accurate  positional  and  ID 
information  available  on  all  combat  systems. 
Fundamentally  it  means  that  any  Battle  Group 
commander  can  shoot  a  TIQ  level  4  track  with 
confidence  that  he  is  hitting  the  right  target  and 
is  not  shooting  blue  or  white  forces. 

Level  5  is  a  level  that  is  being  looked  at  for 
the  future.  It  is  being  reserved  in  case  the 
current  Navy  CEC  or  future  Joint  Composite 
Tracking  Network  (JCTN)  can  provide  unique 
contributions  to  TIQ.  At  a  fundamental  level, 
the  sensor  netting  provided  by  CEC  provides  a 
faster  determination  of  3t.  The  composite  ID 
capability  of  CEC  enables  a  more  rapid 
resolution  of  3i.  Rapid  resolution  of  3i  and  3t 
means  an  earlier  achievement  of  TIQ  Level  4. 
The  real  question  for  Level  5  is  whether 
CEC/JCTN  provides  any  unique  information, 
other  than  faster  resolution  of  3i  and  3t,  that 
could  enhance  Battle  Group  situational 
awareness  or  engagement  capability. 

It  should  be  noted  that  the  TIQ  levels  are 
not  available  to  the  Battle  Group  commanders  as 
they  are  fighting.  TIQ  is  determined  by 
comparing  the  Battlegroup  perception  of 
kinematics  and  ID  as  it  is  shared,  in  relation  to 
absolute  truth.  In  other  words,  TIQ  can  only  be 
known  when  the  shared  information  is  compared 
to  ground  truth  information.  This  ground  truth 
is  available  in  the  DEP  via  the  recorded 


Distributed  Interactive  Simulation  (DIS) 
position  information  for  the  track.  Ground  truth 
is  available  in  live  exercises  by  recording  GPS 
positional  information  for  each  track  under 
evaluation. 

A  very  broad  scope  of  information  is 
inherently  included  into  the  TIQ  levels.  TIQ 
includes  the  inputs  of  sensor  performance, 
system  performance  (meaning  the  performance 
of  every  computer  and  computer  program  on 
each  combatant),  the  interoperability  of  all  units, 
the  performance  of  the  operators  involved  as 
well  as  the  impact  of  rules  of  engagement  (ROE) 
and  tactics,  techniques  and  procedures  (TTPs) 
that  govern  their  decisions.  This  opens  the 
possibility  to  measure  the  contribution  of 
individual  systems/subsystems  and  processes  as 
they  impact  the  overall  performance  of  the 
Battle  Group  system. 


BFIR  Data  Extraction 

The  BFIR  team,  in  addition  to  defining  TIQ 
as  a  measure,  also  determined  the  means  to 
collect  the  information  that  makes  up  TIQ.  This 
consisted  of  identifying  the  key  combat  systems 
in  a  Battlegroup  that  contribute  to  TIQ  and 
developing  a  common  list  of  information  that 
must  be  extracted  from  each  combat  system 
including  track  position,  velocity  and  heading. 
The  team  set  up  these  measures,  data  collection 
processes  and  the  algorithms  and  utilities  that 
could  compare  these  measures  to  ground  truth 
and  develop  the  final  TIQ  values  for  any 
exercise. 

DRM  Scenarios 

The  BFIR  team  also  established  a  set  of 
baseline  scenarios  that  stress  the  various  levels 
of  TIQ  in  an  operationally  significant  setting. 
These  scenarios  were  extracted  from  the  Design 
Reference  Missions  (DRMs)  that  were  recently 
developed  as  an  operationally  representative 
reference  mission  for  analysis.  The  basic  BFIR 
scenario  places  the  carrier  Battle  Group  off  of  a 
coastline.  A  commercial  airway  is  represented 
over  the  landmass.  Hostile  aircraft  mimicking 
commercial  aircraft  depart  from  the  airway  and 
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launch  sea-skimming  missiles  toward  the  carrier. 
In  the  most  rigorous  scenario,  shore-based 
Transporter  Erector  Launchers  (TELs)  also 
launch  sea-skimming  missiles  toward  the  carrier 
for  an  ultimate  raid  size  of  8  inbound  targets. 

These  DRM  scenarios  have  been  converted 
into  DIS  scenarios  for  execution  in  the  DEP  and 
are  also  the  basis  for  the  live  events  that  have 
been  executed  to  measure  live  Battle  Group 
performance. 

BFIR  Products 

One  of  the  primary  products  of  a  BFIR 
analysis  is  the  TIQ  plot  as  seen  on  the  right-hand 
side  of  Figure  V.  The  horizontal  axis  is  defined 
as  time-to-go  (in  seconds)  to  the  high-value 
target  (the  carrier  in  this  case).  This  axis  is  read 
from  right  to  left  as  the  target  flies  toward  the 
high-value  target.  The  vertical  axis  is  TIQ 
starting  with  zero  at  the  origin  and  progressing 
toward  level  5.  Overall,  this  plot  describes  the 
total  situation  awareness  held  by  the  Battle 
Group  combatants  as  the  target  flies  inbound  and 
the  Battle  Group  units  work  to  resolve  the 
position  and  ID  of  one  target. 


As  shown  in  Figure  V,  the  first  example  of 
measured  TIQ  is  illustrated  on  the  TIQ  plot  at 
about  90  seconds  time-to-go.  The  plot  indicates 
a  dual  track  on  the  target  as  well  as  two  IDs, 
hostile  and  unknown.  In  this  case,  neither  3i  nor 
3t  have  been  achieved  so  the  track  is  held  at  TIQ 
level  2.  At  70  seconds  time-to-go  the  Battle 
Group  was  able  to  resolve  both  3i  and  3t  at  the 
same  time  and  the  TIQ  jumps  to  level  4.  As 
seen  on  the  displays  at  the  lower  left  there  is  one 
track  and  one  ID  (hostile)  being  shared  on  all 
units  and  both  the  kinematics  and  ID  are  correct 
according  to  ground  truth.  The  Battle  Group 
was  able  to  maintain  level  4  all  the  way  in  to  the 
carrier  until  one  combat  system  had  a  problem 
measuring  the  speed  of  the  target  and  the  TIQ 
dropped  to  level  3i  -  identification  was  still  held 
correctly  but  3t  was  not  maintained. 


Lincoln/Truman  BFIT 

Now  that  we  have  established  TIQ  and 
understand  how  to  interpret  the  TIQ  levels  a 
wealth  of  information  is  made  available.  The 
BFIR  team  is  now  writing  the  BFI  CRD  utilizing 
the  understanding  of  TIQ  to  establish 

meaningful  measures  with 
meaningful  values  for 
performance  thresholds  and 
objectives.  The  ability  to 
measure  TIQ  and  all  of  the 
associated  sub-metrics  enables 
detailed  analysis  of  the 
contributors  and  detractors 
that  make  up  overall  TIQ. 

The  BFIR  team  can  go  back 
into  the  data  and  focus  on  a 
specific  threat  and  how  the 
Battle  Group  handled  that 
threat  as  well  as  focus  on  the 
contributions  of  an  individual 
unit  within  the  Battle  Group. 
Eventually  this  will  help  the 
acquisition  community  to 
implement  improvements  that 
will  lead  to  overall  Battle 
Group  performance 
improvements. 
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Figure  VI  ~  Measured  TIQ  Improvement 
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Changed  the  AEGIS  DDG-51  and  DDG-57 
Computer  Programs  from  Baseline  5.3.6  to  5.3.7 


The  two  plots  shown  graphically  in  Figure 
VI  illustrate  the  insights  provided  by  the  TIQ 
measurements  when  they  are  exercised  in  the 
DEP.  The  left-hand  plot  shows  the  TIQ  levels 
achieved  for  a  single  target  flying  toward  the 
Lincoln  Battlegroup  during  the  Lincoln/Truman 
BFIT.  The  plot  shows  that  the  Battle  Group  did 
not  achieve  TIQ  level  2  until  35  seconds  time- 
to-go  and  was  unstable  even  at  that  level.  There 
was  a  brief  jump  to  level  3t  but  the  Battle  Group 
never  achieved  level  4. 


shows  that  the  Battle  Group 
achieved  level  2  with  about  90 
seconds  time-to-go  and 
achieved  a  good  level  4  at  70 
seconds  time-to-go.  Level  4 
was  maintained  for  the 
remainder  of  the  scenario 
except  for  a  speed  failure  near 
the  end. 

Engineers  as  well  as  Fleet 
operators  can  now  see  graphic 
and  detailed  analytical 
differences  between  Battle 
Groups  and  components 
within  Battle  Groups.  This 
level  of  analysis  enables  the 
engineering  community  to 
dissect  a  Battle  Group  and  its 
components  and  derive 
improvements  to  capabilities  that  will  improve 
overall  Battle  Group  performance. 

Impact  to  Force  Protection  -Air  Defense 
Decision  Point 

On  the  plot  shown  in  Figure  VII,  the 
distance  to  the  carrier  is  plotted  on  the  x  and  y 
axes  with  the  threat  inbound  toward  the  carrier 
at  the  0,0  point. 


A  primary  contributor  to  this  low 
TIQ  performance  was  the  AEGIS 
baseline  5.3.6  combat  system  installed 
in  the  DDG-57.  Baseline  5.3.6  had 
many  known  performance  and 
interoperability  issues  that  were 
causing  problems  with  the  shared 
situational  awareness  of  the  Battle 
Group.  The  follow-on  baseline  5.3.7 
fixed  these  problems  and  has  been  a 
big  improvement  for  the  Fleet.  The 
magnitude  of  the  performance 
improvement  can  be  seen  in  the  right- 
hand  plot.  In  this  case,  the  baseline 

5.3.6  computer  programs  were 
removed  from  the  destroyer  and  the 

5.3.7  system  installed.  The  DIS 
scenario  was  replayed  in  the  DEP  and 
accurately  repeated  the  entire  scenario.  The  plot 


Figure  VII-  Weapons  Engagement  Zone  Impacts 


The  AEGIS  destroyers  and  cruiser  are 
arrayed  in  a  typical  fashion  with  regard  to  the 
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carrier.  The  TIQ  level  changes  are  denoted  by 
the  numbered  circles  along  the  threat  axis.  The 
plot  also  denotes  with  various  colors  the 
weapons  engagement  zones  of  the  combatants. 
The  Standard  (area  defense)  missiles  of  the 
AEGIS  platforms  are  depicted  in  dark  gray.  The 
self  defense  missiles  (SeaSparrow)  of  the  carrier 
come  in  to  play  with  the  light  gray  zone.  Other 
weapons  engagement  zones  including  the  F-14 
Combat  Air  Patrol  and  the  Carrier’s  Close  In 
Weapons  System  (CIWS)  are  not  depicted  to 
improve  clarity. 

The  potential  engagement  zone  of  each 
weapon  is  depicted  by  the  outer,  dashed  arc  of 
color  versus  the  inner  solid  color  region  for  each 
weapon.  For  example,  the  potential  engagement 
zone  of  the  Standard  missiles  is  defined  by  the 
outer  gray  arcs  and  the  actual  engagement  zones 
against  this  threat  are  defined  by  the  inner  solid 
gray  circles.  The  difference  between  potential 
and  actual  engagement  zones  is  determined  by 
the  TIQ  level  versus  range.  For  instance,  the 
TIQ  level  jumps  briefly  to  level  4  at  the  first 
point  on  the  chart  but  falls  back  to  Level  2 
shortly  thereafter.  When  Level  4  is  finally 
achieved  and  maintained,  the  actual  performance 
of  the  Standard  missiles  is  depicted  for 
each  of  the  AEGIS  combatants.  In 
essence,  this  inner  zone  of  Level  4  is 
the  only  point  at  which  the  Battle 
Group  commanders  can  commit 
Standard  missiles  and  be  confident  that 
they  are  hitting  the  correct  target. 

This  presentation  of  analysis 
results  immediately  opens  questions 
for  the  Fleet  and  the  acquisition 
community.  These  questions  can 
rapidly  and  logically  flow  down  in  the 
following  manner; 

•  How  can  we  ‘buy-back’  the  lost 
engagement  capability  of  our  area 
defense  missiles? 

•  In  essence  -  how  can  we  get  to 
TIQ  level  4  faster? 

■  How  do  we  achieve  3i  faster? 

•  Improve  ID  sensors/systems 

•  Cooperative  ID  systems 


•  Non-cooperative  systems 

•  Etc. 

■  How  do  we  achieve  3t  faster? 

•  Improve  active  sensors 

•  Improve  passive  sensors 

•  Multi-source,  multi-spectral 
sensor  integration 

•  Improve  support  services 
(gridlock,  correlation,  etc.) 

•  Sensor  netting 

•  Etc. 

In  essence,  given  a  testbed  and  a  yardstick, 
a  good  engineer  can  balance,  improve  and 
optimize  a  system  for  maximum  capability. 
Through  the  DEP  and  the  BFIR  programs  those 
tools  are  now  available  at  the  Battle  Group 
system  level  and  the  potential  for  effective 
capability  improvement  is  immense. 

Live  BGSIT  experience 

Figure  VIII  is  included  to  show  that  the 
same  BFIR  capabilities  demonstrated  and 
utilized  in  the  DEP  have  been  utilized  many 
times  in  the  live  environment. 


The  information  depicted  is  from  a  recent 
live  BGSIT  event.  During  this  event,  the  Battle 
Group  and  the  aggressor  aircraft  tried  to  emulate 
the  DRM  scenarios  as  closely  as  possible.  The 
BFIR  team  collected  the  appropriate  data  points 
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and  ran  the  data  through  the  BFIR  algorithms. 
The  BFIR  team  generated  the  standard 
TIQ/time-to-go  charts  as  well  as  the  chart  to  the 
right  that  breaks  out  the  26  sub-metrics  and  how 
well  the  Battle  Group  under  test  relates  to  a 
‘baseline’  of  those  metrics. 

The  BFIR  metrics  have  proven  very  useful 
during  the  Battle  Group  staff  debrief  meetings 
after  the  BGSIT  exercise.  The  TIQ  plots  are 
very  meaningful  to  the  operators  and  have  been 
useful  for  event  reconstruction  and  overall 
evaluation  of  team  performance.  The  left-hand 
plot  in  Figure  VII  alerted  the  Battle  Group  staff 
that  simulated  ROE  and  TTP  were  not  being 
properly  implemented  by  the  operators  within 
the  Battle  Group.  In  many  cases  with  an 
aggressor  inbound  the  operators  were  not 
elevating  the  simulated  threats  to  hostile  in  a 
timely  manner.  The  TIQ  information  provided 
tangible,  timely  information  to  help  the  Battle 
Group  team  debrief  and  plan  for  improved 
execution  on  subsequent  days  of  the  BGSIT. 

BFIR/DEP  Mutual  Support 

There  is  a  very  real  synergy  and  mutual 
support  between  the  DEP  and  BFIR  programs. 
The  DEP  provides  a  precise,  repeatable 
environment  in  which  the  BFIR  metrics  can  be 
executed  repeatedly.  This  enables  the  kind  of 
what-if  testing  and  incremental  analysis  that  is 
essential  to  the  development  of  new  capabilities 
for  the  Fleet.  At  a  more  fundamental  level,  the 
DEP  data  extraction  network  assists  the  BFIR 
team  by  transferring  megabytes  of  data  and 
ground  truth  information  from  around  the 
country  to  the  BFIR  analysts  within  minutes  of  a 
test  execution. 

In  the  other  direction,  the  BFIR  work  has 
provided  a  powerful  set  of  new  metrics  to  be 
applied  within  DEP  testing.  The  BFIR  scenarios 
are  now  included  in  the  basic  set  of  tests  run  for 
every  Battle  Group  with  two  nights  of  BFIT 
testing  devoted  to  BFIR  metrics  collection  for 
each  Battle  Group.  These  metrics  will  allow 
comparison  of  performance  between  Battle 
Groups  as  well  as  a  measure  of  progress 
between  Battle  Groups.  The  eventual 
development  of  the  BFI  CRD  may  lead  to  a  full 


set  of  Battle  Group  performance  requirements 
that  will  enable  full-spectrum  certification  of 
Battle  Group  capabilities. 

CONCLUSION 

Achieving  Battle  Group  or  Battle  Force 
interoperability  requires  a  multi-pronged 
approach  driving  toward  a  common  systems 
engineering  process.  Today  we  have  the  D-30 
process  that  dictates  a  disciplined  Battle  Group 
configuration  management  process  with  defined 
milestones,  events  and  exit/entry  criteria.  The 
DEP  is  also  in  place  and  fully  operational  for  the 
Anti-Air  warfare  mission.  The  DEP  has  made 
significant  contributions  by  treating  the  Battle 
Group  as  a  system  and  testing  all  components  of 
the  Battle  Group  in  a  rigorous,  repeatable 
environment.  In  addition,  as  a  Battle  Group 
testbed,  we  are  just  beginning  to  realize  the 
ability  of  the  DEP  to  support  system 
development  programs  as  well  as  system 
acquisition  decisions  via  performance  analysis. 
Finally,  the  BFIR  program  is  providing 
quantitative  analysis  of  Battle  Group 
performance.  This  information  is  critical  to 
bounding  the  performance  required  of  US  Battle 
Groups  via  BFI  CRD  development  as  well  as  by 
measuring  current  and  future  performance  of 
Battle  Groups  and  Battle  Group  system 
components  as  they  are  acquired.  T ogether, 
these  three  initiatives  form  a  solid  foundation  for 
achieving  Battle  Groups  that  are  greater  than  the 
sum  of  the  capabilities  of  their  individual  ships 
and  aircraft  systems. 
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